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DECLARATION OF PETER R. FENNER UNDER 37 C.F.R. §1.131 
I, Peter R. Fenner, being of legal age and capacity, upon personal knowledge, declare as follows: 

1 . My name is Peter R. Fenner. 

2. I am the inventor of the subject matter set forth in claims 19-28 and 32-40 of the patent 
application identified above ("my invention"). 

3 During 1989 I was the Vice Commodore of the Snipe Class International feeing 
AssociaL (ScSS?» inLational sports option. During 1989, I was also V 1C e Present of 
Engineering of Lightbus Technology, Inc. 

4 I conceived my invention prior to February 9, 1989. ™"*J%^ 9 ^^ 
spitted a pr o P osa, to the "Space ^™ S^ 

under the Small Business Innovation Research (SBIK) program, im » p v ' a true and correct 

technique for U.S. Navy traffic in a multimedia environment" described my invention. A true ana 
copy of the proposal as submitted is attached hereto as Exhibit A. 

< Prior to February 9 1989, 1 made inquiries at various companies to gather infonnatiorion 
parts, such as data^^ 

6 . Between February 9 and February 16, 1989 I 

toolkit used to build networking software, had discussions with a a soflw J 

approaches for the design of software for the J***^ 

contractor (the "Software Contractor") about developing the software lor me ruv 

ray invention and about the costs of such development. 

n ^v-.-tv ?l 1989 I was performing my duties as Vice 

7. Between February 17 and February 21,^ ^, S P sa Uing meet and inquired about 
Commodore of SCTRA and made travel arra nge for ^ttendin Japan £. the Snipe 
the possibility of acquiring discounted airline tickets for the U.S. sailing team o y 

World Championships. 
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8. Between February 22 and February 27, 1989, I inquired about networking software 
products from a software company, FDDI products advertised by another company, and had discussions 
with a company to determine their interest in testing an FDDI switch/router based on my invention. 

9. On February 2S, 1989, in my capacity as Vice Commodore of SCIRA, I had discussions 
with other officers of SCIRA regarding the logistics of shipping boats from the U.S. to Japan for the 
Snipe World Championships and some other SCIRA issues. 

10. Between March 1 and March 6, 1989, I discussed with an employee of the National 
Aeronautics and Space Administration (NASA), the possibility of having my invention tested by NASA 
using the FDDI switch/router. During this time, in connection with my invention, I also did research on 
automatic startup and synchronization of bridge nodes on a token ring network and had discussions with 
an employee of a company regarding FDDI adapters. 

1 ] . Between March 7 and March 15, 1989, 1 was performing my duties as Vice Commodore 
of SCIRA, which included extensive travel. During this time, I sent a letter to American Airlines 
regarding getting travel discounts to Japan for the U.S. sailing team and made travel arrangements to go 
to Chicago for the U.S. Yacht Racing Union Spring Meeting. During this time I also participated in the 
Snipe Midwestern Championships in Florida and had discussions with past and present officers of SCIRA 
regarding Snipe Class International issues raised in Florida. 

12. On March 16, 1989, 1 made travel arrangements to go to Houston, Texas to discuss 
testing of a prototype of a FDDI switch/router based on my invention with an employee of NASA. I also 
had discussions with the Software Contractor. 

13. Between March 17 and March 19, 1989, 1 participated in the U.S. Yacht Racing Union 
Spring Meeting in Chicago. At this meeting, I requested and received funding from USYRU for travel 
for U.S. competitors to the Snipe World Championship in Japan, 

14. Between March 20 and March 22, 1989, in connection with developing an FDDI router to 
test my invention, T had discussions with a company regarding their inter-computer communication 
products, made inquiries at another company to determine their interest in testing a FDDI switch/router 
based on my invention, had discussions with a company to explore the possibility of the joint 
development of the FDDI switch/router and went to NASA for discussions regarding the possibility of 
testing of the FDDI switch/router. 

15. Between March 23, 1989 and March 27, 1989, I was performing my duties as Vice 
Commodore of SCIRA and, among other things, had discussions with a SCIRA member regarding details 
of bidding for the 1990 North American Snipe Championships. 

16. On March 28, 1989, I had discussions with a computer company regarding the 
configuration of a personal computer for development work related to my invention. 

17. On March 29, 1989, I had discussions with a SCIRA Executive Director regarding U.S. 
National Championships and Snipe World Championships. 

18. Between March 30 and April 12, 19S9, I had discussions with various companies 
regarding their networking products in an effort to find suitable parts for my FDDI switch/router. During 
this time, I also had discussions with the Consultant regarding design plans and schedules for the software 
for the FDDI switch/router, had discussions with the computer company regarding the personal computer 
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to be used for development work related to my invention, and had discussions with a communications 
company regarding testing my FDDI switch/router. 

19. Between April 13 and April 19, 1989, in my capacity as Vice Commodere of SCIRA, I 
worked on U.S. Yacht Racing Union funding. I also had discussions with a NetBIOS toolkit company 
regarding a possible test site at a communications company in California for testing a FDDI switch/router 
based on my invention. I also acquired a copy of a C language I/O driver source code for the FDDI 
adapter of the toolkit company. 

20. Between April 20 and April 28, 1989, in my capacity as Vice Commodere of SCIRA, I 
had discussions about the logistics of the U.S. National Championships and the logistics of getting boats 
to Japan for the 1989 Snipe World Championships. I also ordered some Ethernet cables for the FDDI 
switch/router. 

21. Between May I and May 5, 1989, in connection with developing the FDDI router to test 
my invention, I performed research on object oriented definition of routing tables. I also started 
negotiations with the Naval Ocean Systems Center (NOSC) on a contract under the SBIR, initiated 
contact with a Computer Science professor (the "Computer Science Professor") who was a subcontractor 
under the SBIR contract and also had discussions with the Consultant who was designing the software for 
the FDDI router. 

22. On May S, 1989, in my capacity as Vice Commodore of SCIRA, I had discussions with a 
former Commodore of SCIRA regarding protocol for a World Board meeting and to get background 
information on long standing international class issues. 

23. Between May 9 and May 23, 1989, in connection with developing the FDDI router to test 
my invention, I researched and was developing the FDDI switch/router access tables, and researched 
multi-cast routing, outbound routing, minimum spanning tree construction and link state operations. I 
also had discussions with the Consultant regarding switch/router simulation parameters. I also gathered 
information on pricing of FDDI adapters for use with my FDDI router, held talks with another personal 
computer vendor (the "Computer Vendor") to determine whether their equipment could be used as a basis 
for my FDDI switch/router, and had discussions with another professor regarding performing subcontract 
work on the SBIR contract. I called the Computer Science Professor to set up a meeting to discuss work 
Statement and contract details for the SBIR contract and had discussions with my contact at the NOSC 
regarding the SBIR contract. 

24. Between May 24 and May 25, 1989, in my capacity as Vice Commodore of SCIRA, I 
had discussions with Snipe Class sailboat builders regarding the number of boats that may be packed into 
a shipping container. I also had discussions with a shipping company regarding special shipping rates for 
shipping boats from Florida to Japan. 

25. On May 26, 1989, 1 met with the Computer Science Professor regarding work statement 
for the SBIR contract. 

26. Between May 27 and May 29, 1989, 1 participated in the Memorial Day weekend regatta 
at a local lake. 

27. Between May 30 and June 7, 1989, 1 researched minimum spanning tree problem and its 
realization in an Industry Standards Organization (ISO) router in connection with developing an FDDI 
router to test my invention. During this time I traveled to NASA to secure a test site for my invention. I 
also had discussions regarding the SBIR contract with the Computer Science Professor. I also received 
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and started reviewing the SBIR contract from NOSC I also had discussions with the shipping company 
confirming special rates for shipping boats from Florida to Japan and made hotel arrangements for U.S. 
Snipe Class National Championships to be held in Florida. 

28. On June 8. 1989, I made an appointment to meet Mr. Mike O'Neil and Mr. Alfred E. Hall 
of the law firm of Gardere & Wynne to discuss the SBIR contract and to discuss preparation and filing of 
a patent application for my invention on my behalf. I also continued my research on the minimum 
spanning tree problem for an ISO router. 

29. On June 9, 1989, 1 met with Mr. O'Neil and Mr. Hall. On that day 5 1 also met with the 
Consultant concerning simulation definitions to test my invention. I also prepared notes on uniformly 
distributed address detection tables for media access level (MAC) bridge, basic address index table 
construction, learning addresses, address index table management, generalized learning process, 
processing of address symbols, and building address index tables in preparation for my meeting with Mr. 
Hall the following morning regarding the patent application for my invention. 

30. Between June 10 and June 12, 1989, I worked with Mr. Hall on drafting the patent 
application. I also reviewed the draft of the patent application and executed the relevant documents for 
filing on June 12, 19S9. 

3L Between June 13 and June 15, 1989, 1 continued work on the simulation definition for 
testing my invention. During this time, I noticed various typographical and technical errors in the patent 
application filed on June 12, 1989. I informed Mr. Hall of the errors in the patent application as filed on 
June 12, 1989, 

32. On June 16, 1989, U.S. Patent Application, Serial No- 07/367,012, titled '^Message 
Routing System for Shared Communication Media Networks" containing a description of my invention 
was filed in the U.S. Patent and Trademark Office* 

33. All statements made herein are of my own knowledge and are believed to be true and 
correct; and further these statements were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment, or both, under 18 U.S.C. §1001, and that such 
willful false statements may jeopardize the validity of the application for patent commented on herein. 

I declare under penalty of perjury that the foregoing is true and correct. 

Executed on 
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U.S. DEPARTMENT OF DEFENSE D0D No ' 89/1 

SMALL BUSINESS INNOVATION RESEARCH (SBIR) PROGRAM 

PHASE 1 — FY 1989 
PROPOSAL COVER SHEET 

K a N89-037QArmy H Navy GeForce □ OARPA DDNA 
Topic NumberfI«2-J}-3 ' 



Proposal Title: 



□ SDIO 

An addressing technique u.s. Nbw traffic 
in a multimedia ftpv-i rnnment 



_ LIGHTBUS Technolog y , Inc . 
Submitted By: Firm . — ■ 



Address fir>n Goodwin Drive . 

City Richardson. State _TJ£ — Zip Code .25081 

Submitted To: (Activity identified with the topic) Space and Naval Warfare 

Systems Command r Deoart P^nf, Na^gZ 

2511 Jefferson Davis Highway Room IE 5 8 
Address , » — — — 

City At! i ncrtion « __ State JZ^- Zip Code -222 0 2 

Small Business Certification: 

The above firm certifies it is a small busing tirm and meets the definition stated in the Small Business Act 15 U.S.& 
631 and m the Definition Section of me Program Solicitation. 

The above firm certifies that it qualif its as a minority or disadvantaged smajl business as 
defined in the Definition Section of the Program Announcement Yes No 

The above firniTOftifies that it qualifies as a wontan-owned small business firm : Yes No -X — > 

This proposal has been submitted to other US Government agencyifagenciB* or DOD components, or the same 
DOD component. If SBIR proposal, list Topic Number. 



Yes ; Name(s) 

No — 



Disctosure permission statement as follows: 

All data on Appendix A is release information. AH data on Appendix B. tor an awarded contract, it also release. 
Will you permit the Government f disclose the information on Append* ft if your prt^ does not re*u* ^ award, 
to any party that may be interested In contacting you for further information or possible investment . Yes 

Number of employees including all affiliates (average for preceding 12 months) : — 

Proposed Cost (Phase I): $50.00 0.00 Proposed Duration: „±_rr*>nths (not to exceed six months). 

Project Manager/Principal Investigator Corporate Official (Business) 

Peter R- Fe nner Hj R- Farmer 



Name Enqin6erinq Tfr"~ Sftcrefn^/l-rWujgr 



Trtte. 



5 T" 1/4/89 * STV4/89 ~ 

SS^- (214) 783-1349 T ^ne 783-1349 

For any purpose other than to evaluate the proposa.. this data except Appendix A and B ^f^J^Sit 
side the Government and she., not be orated, used, or disOosed in whole or ^JT^^SSil 
awardedtothlsprpposerasarBsultoforin connection with the submission otthls data, the ^^521 S 
the right to duplicate, use, or dolose the data » the extent provide in the funding agreement^ ^SSSS 
notH.iUhecLrnn^^ 

restriction. The data subject to this restriction is contained in page(s) __aU °t tms propuiai. 

appropriate spaces may cause your proposal to be disqualified 

Nothing on this page is classified or proprietary information/data 
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DOD No. 89/1 

U.S. DEPARTMENT OF DEFENSE 

SMALL BUSINESS INNOVATION RESEARCH (SBIR) PROGRAM 

PHASE 1- FY 1989 
PROJECT SUMMARY 

Topic No. N8 9-037 Military Department/Agency _^DL . 



Name and Address of Proposing Small Business Firm 

LIGHTBUS Technology, Inc. 
600 Goodwin Drive 
Richardson , Texas 75081 



Name and Title of Principal Investigator 

Peter R. Fenner - vice Presiden t: of Engineering 

Proposal Title 

An addressing technique for U.S. Navy traffic in a multimedia environme x 
Technical Abstract (Limit your abstract to 200 words with no classified or proprietary information/data.) 

Proposes development of a routing table access method which treats 
network addresses as variable length octet strings without internal 
structure - i.e. as flat addresses - to simplify the handling of mobil 
end-system simultaneously connected to multiple access points. Specific 
routing table access and management techniques are proposed which allow 
rapid access in a single probe while limiting the size of the table 
to the currently active network addresses- Hierarchical, flat, physical, 
logical or a mixture of address structures are all accessed with equal 
ease using the same process. Multicast message routing is efficiently 
processed. 



Anticipated Benefits/Potential Commercial Applications of the Research or Development 

A high' speed, ISO (GOSIP) Internet process which handles multi-cast 
messages to multiple, mobil hosts will be possible using the proposed 
approach. The technique is also applicable to real-time database 
applications such as a network name service. 



List a maximum of 8 Key Words that describe the Project, 

ISO Internet , Network Addressing, Routing Tables, Multi-Cast Routing, 
Storage Allocation 

Nothing on this page Is classified or proprietary information/data 
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a. SIGNIFICANCE OF THE PROBLEM AND OPPORTUNITY 

LIGHTBUS Technology, Inc. proposes to develop addressing formats that support U.S. 
Navy traffic types without imposing a heavy burden on communication resources. 
Specifically, we propose an internet router based on a flat logical address space which 
provides efficient routing of both multi-cast and uni-cast packets independent of the internal 
network address foimat or structure* The proposed arithmetic coding technique can handle 
hierarchical, flat, or other address structures with equal ease and efficiency using 
reasonably sized memory tables. 



Our proposal includes three specific innovations in the design and implementation of 
internet routing tables. These are: 



1 . Employ a reversible arithmetic code compression technique to reduce the logical 
network address of up to 160 bits to a unique integer directory index smaller than 32 
bits while preserving any hierarchical ordering of the network address. Efficient code 
compression techniques have not been applied to large, sparse address spaces as a 
directory access method. In the absence of such techniques, hierarchical address 
structures have been employed to reduce the routing table size. 

2. Access the routing tables using the network address as a variable length octet string 
with no known internal structure. This new flat address routing approach overcomes 
the motives underlying the use of hierarchical routing while simplifying the problems of 
addressing highly mobile end systems (e.g., computers on ships, aircraft) that are 
simultaneously connected to multiple communications paths and employ multi-cast 
message traffic. 

3. Employ dynamic hashing, dynamic memory allocation, and caching techniques to 
automatically adjust the size of the routing table to accommodate the number of end- 
system addresses currently active in the communications system. These techniques 
provide a selection of approaches to allow graceful degradation of the routing efficiency 
when the memory available for routing tables is full. Approaches include moving up the 
hierarchy (i.e., use fewer index bits) and caching the most recently used active address 
records. Selection and control of the approach used can be automatic or under the 
command of a network management authority. 



LIGHTBUS Technology proposes an internet routing table structure that uses a flat logical 
address structure to provide fast and efficient route processing of both multi-cast and 



Use or disclosure of data contained on this sheet i$ subject to the restriction on the title page of this proposal 
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LIGHTBUS Technology, Inc. 

uni-cast message traffic. We propose to remove the address structure from the design and 
operatiou of the internet routing by treating the address as an octet string without internal 
structure. This approach is made possible by employing an arithmetic code compression 
technique as a hashing function for the routing table access method. By managing and 
manipulating logical network addresses, mobile end-systems can keep the same network 
addresses as they move from access point to access point. Similarly, group addresses may 
be allocated without regard to their physcial network connection. 

An overview of the proposed arithmetic coding routing table design is shown in Figure 1. 
Arithmetic code compression uses the statistics of occurrence of various octet values to 
compress an encoded network address into a shorter unique bit string which preserves the 
numerical hierachy of the original network address. If the compressed bit string to too long 
to access the available directory, then the string may be truncated by removing some low 
order bits (i.e., move up the hierarchy.) Further reduction, if necessary, is obtained by 
adjusting (i.e., teshing) the bit string modulo the size of the directory to create an index 
into the directory. Whether truncation or hashing is required is a function of the size of the 
directory relative to the number of valid network addresses; determining the requirement for 
hashing or truncation is a subject of the proposed research. 

The directory contains the compressed address (before truncation or hashing) and pointers 
to the entries for that address in the outbound record and muhi-cast record lists. An 
outbound record contains the routing information for this address when, used as a 
destination, be it uni-cast or muhi-cast. A multi-cast record is accessed using the source 
address of apacket with a group destination (i.e., a multicast) and contains the information 
needed to limit the propagation of multi-cast packets from this particular source. 

Such an approach offers the promise of single probe access while allowing a practical table 
size which varies linearly with the number of active addresses. By processing a flat log.cal 
address structure, we allow the network address design to be placed in the Name Service 
where it can be automatically structured and managed to meet the Navy's overall needs for 
rapid access, transmission efficiency, rapid reconfiguration, arid security. 
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FIGURE 1 ADDRESS COMPRESSION FOR ROUTING TABLE INDEX 
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Hidden Assumptions of Hierarchical Addressing 
A multi-cast message is a single message transmitted by the source to a group of 
destinations. Rather than sending a uni-cast to each member of the group, multi-cast allows 
the internet routing entities to duplicate the packets as necessary to ensure that the message 
reaches till group members. These internet entities must efficiently propagate multi-cast 
packets to networks with group members without burdening nets without group members. 
This requires keeping track of the outbound ports to members of each group. In addition, a 
filtering technique is required to duplicate packets only to low cost routes from the source 
since, without source filtering, a destination station within a group could receive many 
copies of the datagtam transported over different paths. Such multi-cast flooding wastes 
network bandwidth. This multi-cast capability requires a level sophistication in source 
address processing not currently employed in standard ISO internet routers. 

The proposed arithmetic coded routing table design provides direct support for mobile, 
multi-homed, and shared network end systems employing both multi-cast and uni-cast 
messaging while minimizing the effects of the hidden assumptions that have lead to 
reducing the routing table size by embracing hierarchical routing schemes. These hidden 
assumptions and the solutions afforded using our approach are: 

Assumption 1 : The processing load of the router CPU increases as the size of the routing 
table increases. 

Solution: The proposed arithmetic coding routing table access method has a small, fixed 
amount of computation for a fixed sized network address, and the computation varies 
linearly only with a change in the length of the address field. The amount of computation 
required to process one address is independent of the routing table size and the number of 
active network addresses. 

Assumption 2: Computer memory is a scarce and expensive resource; therefore, 
reducing the amount of memeory needed should be a primary design goal 

Solution: Our proposed approach uses whatever memory is available. The more memory 
available, the better the performance. With the laige sizes and modest cost of memory for 
today's computers, we believe it is clearly cost effective to use this additional memory 
wisely to achieve the operational flexibility demanded by modem naval environments. 
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LIGHTBUS Technology, Inc. 

Assumption 3. Servicing a logical network address structure requires more router CPU 
processing than one based on physical addresses. 

Solution: The proposed arithmetic coding with dynamic hashing has the same processing 
for any underlying address structure, be it logical, physical, flat or hierarchical. We 
propose providing for network addresses what memory mapping provides for computer 
programs, allowing the network addresses to be compiled and executed in a logical address 
space which is dynamically mapped to the physical space at run time. 

Assumption 4: Hierarchical routing is deterministic and operates in real time. 

Solution: It is, but only for the level of the hierarchy it can see! Any faults, congestion^or 
alternate paths that exist below its level cannot be incorporated into a routing solution. The 
proposed flat routing has the option of an adjustable, two level hierarchy which allows the 
router or the network manager to tune the routing operation and its associated inter-router 
traffic 

Technical Approach 

The U.S. Navy and DOD communication networks services its stationary and mobile users 
with a wide variety of media ranging from satellite links, high frequency radio, the Navy 
signal net to local area networks (LANS), DDN, and dedicated point-to-point circuits See 
Figure 2.) Local area networks are proliferating in land based office environments as well 
as command and control support areas. Shipboard LANs, including Safenet I (IEEE 802.5 
Token Ring) and Safenet H (ANSI X.3-139 FDDI), are being developed to support 
command, control, communications and intelligence (C3I) on board U.S. Navy combat 
vessels. The use of standard ISO internet protocols and the development of very high 
performance, low latency packet switched gateways between these networks is critical to 
reliable communications during crisis and engagement scenarios. 

LIGHTBUS Technology will focus on the design issues associated with addressing and 
routing. Our primary goal is to demonstrate the technical feasibility of using a flat network 
address routing table directory structure to efficiently support both multi-cast and uni-cast 
routing. Efficient multi-cast routing in the OSI internet environment requires source address 
evaluation to prevent unnecessary flooding of the network with multi-cast packets. 
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AIRCBAFT.SEA_COMMAND.100 




SHIP 



AS AIRCRAFT.SEA_COMMAND.100 MOVES FROM STATION 1 TO 2 AND 
THEN TO 3: 

. ROUTER 1 DETECTS AIRCRAFT AND UPDATES NETWORK 

. ROUTER 2 THEN DETECTS AIRCRAFT AND UPDATES NETWORK 

. ROUTER 1 DISCONNECTS AND UPDATES NETWORK 

. ROUTER 3 DETECTS AIRCRAFT AND UPDATES NETWORK 



FIGURE 2 MULTI-HOMED, MOBILE HOSTS 
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LIGHTBUS Technology, Inc. y 

Ultimate Benefit of Flat Address Routing Directories. The proposed 
program will provide the U.S. Navy and perhaps the entire DOD with a very fast, 
automatically expandable, source filtered ISO internet routing scheme totally independent ot 
the internal logical or physical structure of the network addresses it is routing. Using our 
approach, addresses are just unique numbers represented by a string of octets of known 
length. Each internet router learns the location of these numbers within the network either 
from the internet protocol traffic, from the source addresses of the packets it receives, or 
from a network management protocol* 

Address independent ISO routing tables provide the following direct benefits: 

Provides a very fast routing table access scheme supporting fast packet switch 
designs for very high-speed media such as FDDI (SAFENET n) and DS3 data 
circuits. 

Allows source address filtering for efficient multi-cast operation and security 
partitioning of the network* 

Allows independent automatic generation and management of network 
addresses from a user name space by a network name service. The same 
internet software can be used by different networks with different address 
structures. 

Allows for orderly expansion, restructuring, and redesign of the user name 
space without changing the internet code or table structure. In fact, a new name 
space and its attendant new address structure can coexist during a name space 
structure change, allowing the change to he phased in without system 
downtime. 

Reduces life cycle system costs because the ISO internet routers automatically 
adapt to network changes and the can be expanded without routing table 
modification. 

Approach to Designing Multi-Cast Routing Tables. The IP.ISO 

internet protocol provides a connection-less or datagram service between stations on a 
network. Data to be sent from one station to another is encapsulated by the Network Layer 
in an internet datagram with an IP header specifying the global network addresses of the 
destination and source station. This IP datagram is then encapsulated in the logical link 
control (LLC) and physical layer protocol headers and sent to the network. A router 
removes the incoming physical and LLC header, looks up the destination and source 
addresses in its routing table, selects the appropriate outbound link (or links in the case of a 
multi-cast) from the routing table choices, and passes the IP datagram packet to those 
channels for LLC encapsulation and transmission. With multi-cast datagrams, the router 
must determine which outbound links represent the shortest paths from this particular 
source to the group destinations and duplicate the packet for each shortest path. 
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The ISO internet protocol QF) header has four parts. These are: 

PART LENGTH 

Fixed 9 octets 

Address variable between 2 and 512 octets 

Segmentation 5 octets 

Options variable 

In the IP.ISO header the addresses are of the form: 

Destination address - Length(l octet), Address_octets 
Source address = Length(l octet), Address_octets 

From the IPJSO header format we see that the starting position and length of both the 
destination and source address fields are known. Therefore, the proposed flat address 
routing table directory structures have available the length and values of the address octets 
to locate a unique table entry for that address. Sources addresses are also destinations and 
one directory is kept for both with different pointers to the outbound and multi-cast 
records. 

Multi-Cast Routing. Efficient multi-cast requires some evaluation of the shortest 
route to all members of the group from the source location. The approach employed 
depends on the routing technique* Early ARPAnet used Distance vector routing, but has 
since migrated to Link-state routing, also known as "New-ARPAnet" or "Shortest-path- 
firsf* icuting. The Link-state algorithm has been proposed by ANSI as an ISO standard for 
intra-domain routing (ISO TC97 SC6). We propose developing a directory and routing 
table structure for the Link-state approach. 

The ISO internet routing task is self learning- The routing information is entered into the 
routing tables as a result of the internet routing protocol activity or network management 
protocols* When a router starts up, it sends out "I am here* messages using the internet 
routing protocol. All the adjacent routers send back IP routing protocol packets which, 
when combined with the inbound channel, contain the information necessary to fill in the 
routing tables for all active internet addresses. 

When processing a multi-cast, the internet task uses both the destination and source address 
to access the routing table to obtain information defining which outbound ports should be 
used for a multi-cast to this group (destination address) from this source. This multi-cast 
routing table keeps much more information than uni-cast only routing, including data about 
the source of a multi-cast message, and has the form shown in Table L 

Table I Multi-Cast Routing Table Data 

Source and destination Outbound Route Source Mul ti-Cast Route 

Destination Address Costs Costs 

(128 bits) (number of routes) (number of routes) 

x (8 bits per route) x (8 bits per route) 

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal. 
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This two dimensional array is potentially very laige; up to 250 bytes per address times the 
number of endpoint addresses. Several facts concerning the operation of the routing table 
can be used to reduce the operational size of the table, including: 

• Both the outbound and multi-cast route costs are only needed for the ports which lead 
to that address, not every incident port on the router. 

Only source addresses which have sent packets to a group address require the 
multi-cast route cost information- 

Group addresses cannot be sources, so they do not need the multi-cast data. 

Only a portion of the total system addresses are active at one time, so all the valid 
addresses do not need to be resident all the time. 

Our proposal is to use code compression of the address plus dynamic bashing and dynamic 
memory allocation to store the currently active addresses in the routing table, thereby 
reducing the table to a practical size for use on contemporary microprocessor systems. 
Table II shows a comparison of various access methods. 



Table II Routing Table Access Methods 



Table Structure 
Sorted Tables 
Trees 

Hashed Tables 



Amount of Memory Used 
[times a constant] 

- number of addresses 
[grows linearly] 

~ expOength of address) x 
(number of addresses) 
[grows geometrically] 

= number of addresses 
[grows linearly] 



Relative Speed of Access 
[times a constant] 

~ log(number of addresses) 
[slows with more addresses] 

= length of address 
[constant per octet] 



= length of address 
[constant per octet] 



Since the addresses are extremely large binary numbers (up to 2 1*°), the address must be 
compressed via some technique to a number within the range of current computer 
technology i.e., 16 to 32 bits. Then this compressed address can be used to access the 
routing tables. Ideally, the compression technique would reduce the address field to a 
unique binary number with a number of bits equal to the smallest power of two greater than 
the actual number of valid addresses in the network. This smallest set of bits which will not 
duplicate entries or lose information is called the minimum entropy encoding. The proposed 
technique — arithmetic coding — comes close to achieving the minimum entropy 
encoding. 
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d. PHASE I TECHNICAL OBJECTIVES 



Our overall objective will be to develop practical directory structures and algorithms which 
will operate in real time on available mini and micro computer systems. Our specific 
technical objectives are to: develop a theoretical foundation, determine the memory size and 
processing speed required to execute the algorithms, and conduct a comparative analysis of 
traffic types. 

Develop Theoretical Foundation. A key question relative to the routing table 
application is whether the proposed arithmetic coding directory access method detects all 
valid addresses. This has been an important criterion used in our analysis and development 
of the various methods we have investigated. Under this objective, LIGHTBUS will 
develop a fonnal verification that the method meets this criteria. Such verification may 
dictate some modifications of the proposed procedure to guarantee it will always detect 
valid addresses and reject invalid ones. 

Determine Memory Size and Processing Speed Required, in order 

to select and configure a computer system to perform the internet routing function using the 
proposed access method* numerical relationships must be established which characterize 
the memory size, memory speed, and processing speed needed for a particular data rate and 
number of network addresses. These relationships can be used both to compare various 
methods and to size a computer to meet a specific application requirement. 

For the proposed arithmetic coded routing table access method, this project will provide 
specific numerical relationships which allow the computation of the memory size, memory 
access speed, and processor speed necessary to perform the access method for a specified 
data arrival rate and a specified number of netwprk addresses. In particular, the following 
relationships shall be developed: 



Memory size will be the combination of that required by the routing data structure, the 
source related optimum broadcast data structure, and all parameter tables, 

2. The number of integer operations and fteir precision as a function of: 

a. The number of network and multi-cast addresses 

b. The number of octets in the address field 

c. The number of communication ports per node. 

3. The memory access speed in accesses per second and the processor 
computational rate in integer operations per second as a function of the 
aggregate incoming data rate. 

Use or disclosure of data contained on this Sheet is subject to the restriction on the title page qf this proposal. 



1. 




a. The number of network and multi-cast addresses 
b* The number of octets in the address field 
c. The number of communication ports per node. 



-d 0*0/920' d SSE-1 



V8929Q8W2 



la^vH HDSNnn-«"0Jd 6 l = g t eooz-u-w 



[am ppuBis mwi ft ck com \ ib < mmm > m mm 



LIGHTBUS Technology, Inc. 



Comparative Analysis of Traffic Types, Determine under what conditions, 
if any, the access method would be realizable with current microprocessor aid memory 
technology. The specific metric chosen to make comparisons shall be justified by reference 
to actual hardware currently available. The following comparisons will be performed: 

1 . The variation in required memory as the ratio of multi-cast to uni-cast network 

addresses changes from 0% to 100%, 

2* The variation in computations required as the ratio of multi-cast to uni-cast 

network addresses varies from 0% to 100%. 

These are of significant interest because networks in general, and the Navy's traffic mix in 
particular, are using more and more distributed applications where multi-cast is an efficient 
communications mechanism. The cost in memory and processing of providing a 
generalized multi-cast capability at the internet level is an important factor to be able to 
evaluate before committing to an overall network design for the next several decades. 



e. PHASE I WORK PLAN 

LIGHTBUS Technology proposes a six month proof of concept project with three major 
tasks, each with a set of subtasks. Figure 3 shows the schedule for the tasks identified 
below in Table IIL 

Table III Phase I Work Plan 

Task 1 Routing Table Design 

1.1 Technology Review 

1.2 Define Efficiency of Network Address Compression 
L3 Design Data Structures and Algorithms 

Task 2 Proof of Principle 

2« 1 Develop Simulation of Routing Process 

2.2 Trial Runs of the Simulation 

2. 3 Demonstration of Routing Process 

Task 3 Reports 

3 . 1 Monthly Status Reports 

3.2 Final Project Report 
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Figure 3 Phase I Project Plan 
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TASK 1: Routing Table Design 

OBJECTIVE: A complete design of the routing table data structure, access algorithms, 
and processing sequences will be developed using arithmetic code compression of the 
address to produce an index into a dynamically hashed directory which holds pointers to 
the active routing records for that network address. The correctness and processing 
performance of these algorithms and data structures* and in particular the arithmetic code 
compression, will be developed using accepted mathematical and statistical techniques, A 
scholar in the field of computer science and real-time operating system design will be 
employed to review the design, guide the mathematical model development, and monitor 
the validity of the mathematical techniques employed, 

SUBTASK 1.1: Technology Review 

PERFORMED BY: P. R. Fenner and SMU Consultant 

DESCRIPTION: Locate, collect, review, and catalog additional technical and 
engineering literature on topics relevant to compressing binary data strings and accessing 
tables with a large key (network address) space. The following topics are of particular 
interest, as they relate directly to the proposed routing table design: 

Mathematical and statistical analysis of code compression 
Techniques for table access in 0(1) probes 

Design and analysis of dynamic (extensible or virtual) hashing techniques 
Methods for designing perfect hashing functions. 

Within 25 miles of the UGHTBUS facility are three major universities with engineering 
and science libraries: Southern Methodist University and the Universities of Texas at Dallas 
and Arlington, Texas. In addition to their substantial collections of reference materials, the 
hbranes provide on-line access to national technical reference data bases. UGHTBUS 
Technology has also made use of the DTIC in preparing this proposal. 

Use or disclosure of data contained o* this sheet is subject to the restriction on fee title page of this proposal 
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SUBTASK 1-2: Define Efficiency of Network Address Compression 
PERFORMED BY: F- R. Fenner and SMU Consultant 

DESCRIPTION: Use the information collected in the technology review and other 
sources to develop a mathematical relationship between the length of the network address, 
the number of known valid addresses, and the size of the compressed arithmetically coded 
network address. The effectiveness of the proposed routing table access technique depends 
on the efficiency with which arithmetic coding is able to compress the network address 
presented. IT the approach can be shown to be very efficient under the strict parameters of 
the network address, then little or no hashing may be required. The compressed number 
could be used directly as the index to the routing directory. Currently, it is known that 
arithmetic coding approaches a minimum entropy compression and that the number of bits 
needed to represent the encoded ensemble can be estimated statistically. This fact forms a 
starting point for specific analysis in this application. 

If the compression is inadequate to directly access a reasonable sized directory, then two 
other strategies will then be employed to reduce the compressed address to a directory index 
hashing; modulo arithmetic to discard the high order bits, and hierarchical truncation to 
discard lower order bits. The effects of hashing are sufficiently understood that a statistical 
relationship can be developed. The implications of hierarchical truncation (or round-off) are 
heavily dependent on the hierarchical structure of the uncompressed network addresses. A 
relationship between the number of bits truncated from the uncompressed address as a 
function of the bits truncated from the compressed address will be developed to guide this 
operation. The combination of these relationships will provide the parameters necessary to 
constrain the size of the directory necessary for a given number of valid addresses of a 
particular maximum uncompressed length. The results of this analysis may also place some 
useful constraints on the way the Name Service is allowed to create network addresses. 

SUBTASK 1.3: Design of Routing Table Data Structures and Algorithms 
PERFORMED BY: P. R. Fenner and SMU Consultant 

DESCRIPTION: The detailed analysis and modular design of the data structures and 
algorithms for routing table creation, access, and update will be carried out using computer- 
aided software for real-time engineering (CASE) tools available from PROMOD, Inc. 
These tools, PROMOD/RT structured analysis for real-time systems and PROMOD/MD for 
modular design, run on PCs as well as many workstations and DEC/ VAX environments. 
PROMOD provides a complete set of real-time system development tools including source 
code generators for Ada, C, and Pascal. These are important for Phase II, where 
development will employ the Ada programming language. All programming proposed for 
Phase I will be performed in the C language. 

The CASE tools provide Yourdon/deMarko design methodologies combined with the 
Boeing/Hatley extensions for the design and analysis of real-time software systems. 
Features include global analysis over the model and automatic report documentation 
designed to satisfy DOD requirements. By using these tools, LIGHTBUS can enforce 
precise interface definition and information hiding to maximize the reusability of the 
resultant software modules. Using these CASE tools provides LIGHTBUS with a rapid 
and concise method for developing the detailed design of the routing table access method 
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The proposed touting table data structure consists of a dynamically sized hashed directory 
containing the compressed address value and pointers to the outbound and the multi-cast 
cost records. An overview of the basic data structure is presented in Figure 4, These two 
types of cost records are each dynamically allocated lists of currently active addresses, 
linked as timer queues to provide time resident accounting. 

When a record enters the table, it is linked onto the timer queue and given the requested 
Holdjime less the Delta^time of the prior entry. Alternately, the same linked data structure 
can be used to Veep a list of the most recently used records by linking a record to the head 
of the list each time it is accessed. Each record also keeps a count of the number of times 
this record has been accessed for purposes of traffic analysis. The link list data structure is 
used to quickly determine "old" or "least recently used" address records to delete or 
swap*out when memory is full and a new address becomes active. 

TASK 2: Proof of Principle 

OBJECTIVE: Perform a demonstration of the proposed flat logical address routing method 
using a simulation* The complete router operation will be simulated to demonstrate both 
correct operation and performance under the most likely and worst-case scenarios. These 
simulations will be performed on an Apple Macintosh II personal computer using the 
EXTEND simulation program from Imagine That, Inc. EXTEND allow discrete and 
continuous simulations with interactive, graphic control and display of the simulated 
system. This is accomplished by graphically interconnecting simulation blocks which 
contain a function of the input variables. The functions are programmed using C code and 
an extensive set of predefined library routines. Random number generators, queues, 
delays, and other standard simulation functions are also available. 

SUBTASK 2.1: Develop Simulation of Routing Process 
PERFORMED BY: F. T. Elliott and P- R- Fenner 

DESCRIPTION: A simulation of the handling of the IP.ISO header thtougji the complete 
routing process will be designed and developed. Using the EXCEL package on a Mac II, 
the following phases of the HtfSO header processing will be included in the simulation: 

IP-ISO header generator 
Receiver queue to hold incoming packets 
Received checksum processing simulation 
Data compression of the destination address 
Data compression of the source address 
Routing directory hashed table access 
Linked list routing record access 
New uni-cast address active 
New multi-cast address active 
Route decision processing (determine least cost) 
Output queues for two outbound ports 
A segmentation processing delay for each port 
An output checksum processing delay for each port 
Terminating processes for each port to gather delay data 
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FIGURE 4 ROUTING TABLE DATA STRUCTURE 
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These, and other processing blocks which may be needed, will be connected to simulate the 
routiiig process under a conditions of statistically varied speed and distribution patterns of 
the airivii^g packet types, headers, and packet lengths, IPJSO header generator creates 
headers with types (uni-cast or multi-cast), addresses and lengths from random distribu- 
tions for processing through the routing simulation. The ratio of uni-cast to multi-cast 
packets will be statistically variable as will the distribution of the outbound route taken. The 
terminating processes will then accumulate the statistics of the processing delay from the 
receiver queue to the terminating process to provide the results of the conditions being 
simulated. For the critical portions of the arithmetic coding, directory management, and 

record list management, a detailed model of the operation will be used. Other portions of 
the routing operation, such as segmentation and check sum processing, will be simulated 
using appropriate queues and delays., 

SUBTASK 2.2: Trial Rons of Likely Scenarios 
PERFORMED BY: F. T- Elliott and P. R. Fenner 

DESCRIPTION: Using the simulation resulting from Subtask 2,1, a selection of 
simulation runs will be performed to characterize the performance of the routing operation 
under the following conditions; 

1 . For a range of network address lengths (6, 8, 10, 12, and 16 octets) and different fixed 
numbers of valid addresses varying over several orders of magnitude (e.g M 1,000 to 
100,000), run simulations to determine the minimum size of the compressed address 
fox each set of parameters. 

2. For a different fixed-sized hashed directories, vary die length and number of valid 
network addresses and determine the effective utilization and the statistics of "double 
hits" on the same table entry. 

3 . For several different fixed number of valid network addresses and a packet arrival rate 
less than the aggregate outbound port rates, a set of simulation runs to determine: 

a- The variation in cost record list lengths as the ratio of multi-cast to uni-cast network 
addresses changes from 0% to 100% 

b. The variation in throughput delay as the ratio of multi-cast to uni-cast network 
addresses varies from 0% to 100% 



SUBTASK 2.3: Demonstration of the Routing Process 
PERFORMED BY: P. R. Fenner and F. T. Elliott 

DESCRIPTION: LIGHTBUS Technology proposes that the contract technical monitor 
(and contracting officer if required) travel to our facilities in Dallas, Texas to witness a 
demonstration of the routing process simulation developed under the other subtasks of this 
Proof of Principle task. Alternately, the Navy could make available the Apple Macintosh H 
system at the contract monitors facility and Mr. Fenner and Mr. Elliott will travel to that site 
and demonstrate the simulation. This demonstration will require one working day at 
LIGHTBUS facilities, or two days at the Navy's facilities allowing one day to set up the 
demonstration on the Navy's Mac II and one day for the actual demonstration. 



Use or disclosure of data contained on this sheet is subject to the restriction on flic title page of this proposal. 



i OVO/ZSOd QSE-1 



tBS2S98HZ 



10HVH H3SOTH"0Jd IZ'9I £002-1 L-VO 




[aula pjpeis iua)S83l torn mm v < mmm > m mm 



LIGHTBUS Technology, Inc. 



19 



TASK 3: Deliverable Reports 

OBJECTIVE: Provide the U.S. Navy with documentation of the progress of the project on 
a monthly basis and summarize the analytic and numerical simulation results of the 
proposed design and development effort. 

SUBTASK 3.1: Monthly Progress Reports 
PERFORMED BY: P.R. Fenxter 

DESCRIPTION: By the 15th day of each month during the period of the contract, 
LIGHTBUS Technology will submit a progress report which will identify specific tasks 
started, items within tasks completed, tasks completed, and summaries of technical results 
obtained. 

SUBTASK 3.2: Final Report 

PERFORMED BY: P. R* Fenner and F, T. Elliott 

DESCRIPTION: The program final report will contain the details of the results of aU 
tasks and subtasks executed during the life of the contract. These include a summary of the 
pertinent technology discovered during the technology review, a mathematical development 
of the approaches used to define the efficiency of arithmetic coding and its performance 
model, and routing table design and analysis reports as produced by the PROMOD CASE 
tools used in the design process. A description of the various modules developed for 
EXCEL to simulate the routing process and trial run data will be included. Specific 
recommendations concerning further research and development will also be included. 



LIGHTBUS Technology has conducted extensive investigation of arithmetic coding 
combined with dynamic hashing to design a very high speed method for detecting the 48 bit 
IEEE 802.3,4 and 5 physical addresses in a media access controller (MAC). The new 
ANSI Fiber Distributed Data Interface (FDDI) also uses the very same 48 bit address 
format and operates in excess of 100 million bits per second. Specialized hardware is 
required to operate address detection at FDDI rates. 

LIGHTBUS recognised that code compression methods are essentially reversible mappings 
from a large, sparsely populated code space to a compressed space. From the compressed 
key the original codes could be recreated. For over a year we have been investigating 
coding methods to find one applicable to the address detection and routing problem. 

The "LAN Interoperability Study of Protocols Needed for Distributed Command and 
Control" (DTIC ADA154003 March, 1985) identified many of the traffic types, service 
delivery modes, and operational scenarios required for a military environment even though 
this study was directed at the needs of the Air Force. A 1984 u C3l Information Systems 
Inter-network Study" (DITC AD-A14427 April, 1984) identifies the need to consider the 
security issue during system design well before installation. Clearly, the military 
communications environment encompasses some of the most challenging inter-networking 
issues including mobile hosts, broadcast media, multi-cast messages, and an inherent need 
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for secudty. 



Shoch of Xerox (IEEE Proceedings of COMPCON, 1978) reviews the issues of 
"Inter-network Naming, Addressing, and Routing" and compares the implications of 
hierarchical versos a flat address space. Sunshine also reviews "Addressing Problems m 
Multi-network Systems" (IEEE Proc. INFOCOM, 1982) where the problems of multi- 
homing and mobile hosts are explored for an hierarchical routing methods. Sunshine points 
out that using logical rather than physical network addresses would reduce the complexity 
of me packets and simplify the multi-homing and mobile boat issues at the expense of 
complicating the routing tables and processes. The link-state data structures and processing 
requirements for "Multi-cast Routing in Inter-networks and Extended LANs" has been 
studied by Deering (ACM SIGCOMM, 1988) and he identifies the need for source address 
screening to limit multi-cast propagation. In the 1970s, several new versions of hashed 
table access (e.g., extensible, dynamic, and virtual hashing) introduced methods Of 
structuring a hashed file which dynamically expands and contracts with the addition and 
deletion of data records. Per-Ake Larson, one originator of dynamic hashing, has analyzed 
the performance of uniform, external and linear hashing (Journal of the ACM October, 
1983; ACM Transactions on Database Systems December, 1982; and Journal of the ACM 
January, 1988). An insightful survey of dynamic hashing schemes has recently been 
published by Enbody and Du (ACM Computing Surveys June, 1988). 

Jaeschke proposed reciprocal hashing as a method for generating minimal perfect hashing 
functions (Communications of the ACM, December, 1981). Unfortunately, this technique 
for finding a perfect hash function uses an exhaustive search which requires exponentially 
increasing run time when the number of keys exceeds about twenty. Lewis and Cook 
(IEEE Computer October, 1988) have presented a comprehensive survey of hashing 
functions and their strengths and weaknesses. We are unaware of any published Work 
which investigates code compression techniques as a method for generating hashing keys. 

Lelewer and Hirschberg have provided a comprehensive survey of data compression 
methods (ACM Computing Surveys, September, 1987) which compares most of the 
current methods for compressing data files. Whitten presents an explanation of arithmetic 
coding for data compression (Communications of the ACM, June, 1987). In our view, 
arithmetic coding has an advantage over the better known Huffman method m that 
arithmetic coding better utilizes the computational power of modem microprocessors since 
Huffman coding manipulates short bit strings while arithmetic coding employs integer 



The proposed program will employ analytical, simulation, and demonstration code 
fragments to verify that a routing table structure employing dynamic hashing with 
arithmetic coding is a practical and efficient design approach. Specifically, we will show 
that the method provides the following features: 
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1 . Variable length addresses with no known internal structure are used to access routing 
tables with a processing time proportional to the number of octets in the address field 

2 . The size of the routing tables is directly proportional to the number of active addresses 
known to the router and within the practical limits of currently available 
microprocessing systems. 

3 . The computational operations required to access the routing table for any address is 

linearly proportional to the length of the address field and that these computations are 

reasonably performed by currently available microprocessor systems. 

These results provide the critical design parameters necessary to select a microprocessing 
system appropriate for a specified internetwork communication rate and number of 
stations* Our anticipated Phase II project is the design and development of an ISO internet 
router using the proposed routing table structure to switch multi-cast ISO internet packets in 
realtime. 



The proposed ISO internet routing table structure is designed to fulfill specific, known 
needs in the U.S. Navy's communications environment. With the advent of GOSIP, this 
solution to these needs would find wide application throughout the Navy and the DOD, not 
only in the communications routing processors but also in a wide range of host end 
systems where multi-cast address detection and source security filtering are required- As 
ISO protocols migrate into the commercial world where shared media LANs are 
proliferating, an increasing number of LAN applications employ group (multi-cast) 
addressing, and the interconnection of these LANs will demand multi-cast capability to be 
commercially successful. 

The general directory access structures resulting from this research and design project will 
also be applicable to other real-time or high performance table lookup and data base 
applications. Some of these include: 

Design of the directory for the on-line, high-speed network name service which maps 
logical alphanumeric names to network addresses* 

• Design of a high speed or very high-speed address detection logic device which would 
allow a large number of IEEE 802.3, A t or .5 (Ethernet, Token Bus, and Token Ring 
respectively) or ANSI X-3139 FDDI destination and source address to be detected at 
transmission speeds. This operation is essential for fast media access level (MAC level) 
LAN bridge operation, particularly if the networks are carrying packet voice or other 
traffic sensitive to delay. 
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LIGHTBUS Technology, Inc. 22 

LIGHTBUS Technology, Inc. proposes to assign two employees, Peter R- Fernier and 
Friedrich T. Elliott, and a consultant to carry on the project. The consultant is identified 
under Section k. 

j. FACILITIES AND EQUIPMENT 

LIGHTBUS Technology's primary facility is approximately 600 square feet of office space 
at 600 Goodwin Drive Richardson, Texas which is the full-time office of the principal 
investigator (P- R. Fenner). This office houses a modest technical library With copies Of aU 
the technical papers referenced in this proposal and a wide variety ofother computer ana 
commumcationsrelated references. A fully equipped AT&T 6300 (IBM PC compatible) 
personal computer and letter quality Epson printer provide the basic word processing, 
analysis, simulation, and programming tools necessary to perform the proposed rescarc^ 
and development Mr. Elliott personally owns an Apple Macintosh II computer with which 
he plans to perform Che proposed object oriented routing simulations. 

k. CONSULTANTS 

LIGHTBUS Technology plans to contract the assistance of an expert in real-time computer 
data structures from the faculty of the Computer Science Department of Sou Aera Methodist 
University of Dallas, Texas. Dr. Milan Milenlcovic (M.Sc. Georgia Tech and PhD. 
University of Massachusetts) has extensive teaching, industrial and consulting experience 
in computer system and operating system design. His publications include articles, 
technical papers, a monograph on update synchronization in distributed computers, ana a 
book titled, "Operating Systems: Concepts and Design," McGraw-Hill, 1987. 

1. CURRENT OR PENDING SUPPORT 

LIGHTBUS Technology, Inc. has not in the past nor has it currently any support for 
substantially the same as this proposal. 



Use or disclosure of -data contained on this sheet is subject to the restriction on the tide page of this proposal. 



-d 0*0/960 d SSE-1 



V892SS8MZ 



1INVH H3SNnH-»0Jd 



tl-il EOOZ-ll-fO 



[aiU!ipjWsiua]sea]B:Ci:SE0MUe<W/SS8HJ>iuoJJp3A!339y 



LIGHTBUS Technology, Inc. 23 

Peter IL Fenner 
Principal Investigator 
Vice President of Engineering 
LIGHTBUS Technology, Inc. 

B.S. Electrical Engineering, Worcester Polytechnic Institute, 1964 
M.S. Electrical Engineering, Northwestern University, 1966 

Mr Fenner and another Flexible employee founded LIGHTBUS Technology, Inc. in 
August 1987 to design, build and manufacture very high-speed inter- computer 
communications products with emphasis on standard hardware and software wtach will 
sustain coinmunications over emerging fiber optic media such as FDDI and SONA1 . 

Mt. Fenner has over 22 years of experience in the computer and computer communications 
industries inclusing engineering, product planning, and marketing responsibilities. Mr. 
Fennel's areas of expertise are based on broad experience in the real-time computer field, 
including statistical signal processing, real-time operating system design, real-time control 
system data bases, synchronous and LAN communications protocols, real-time simulation, 
seismic data processing, oil and gas drilling and production, and nuclear plant control. 

While at TI, Mr- Fenner was a significant contributor to the theory of statistical filtering 
using the Fatf Fourier Transform (FFT). Following TI, Mr. Fenner held computer system 
design positions with Fishbach & Moore Systems Co. and Systems Engineering 
Laboratories (SEL). Mr. Fenner joined Flexible Computer Corp. of Dallas, J^^J^^f 
as Manager of Product Planning for computer and communication hardware and software 
products. Projects on which Mr. Fenner was the principal designer include: 

Flexible Computer Corp. , 1985- 1 987 . „ 

NASA Langley SBIR for development of a VMEbus floating point array processor lor 
the use with the M68020 based FLEX32 parallel computer. 

SEL/ Gould Computer Systems, 1973-1985 . 
U.S. Air Force Logistics Command HASP remote job entry terminals. 
McDonald Douglas Navy Air Combat Maneuvering Simulator with eight 3Z tut 
super-minicomputers networked to control dual cockpit, air-to-air combat simulations 
of F-4s and F-14s. , , , . 

Boeing B-52 prototype mission simulator with 14 super-mimcomputers networked to 
simulate all operational stations integrated into full mission scenarios. ^ 
Teledyne/Gcotech communications processor for 12 Bisynch, full duplex 
communications lines for -worldwide sensor data collection. 

Fischbach & Moore Systems Company, 1969-1973 

McCormick Place distributed computer control system of 8 remote processors and dual 
master control center processors. . 

Ontario Hydro (Canada) Richview control center with 3 Univac 1 106 mainframes, six 
minicomputer communications processors, two interactive color graphics computers 
with a picture compiler, and 108 remote data acquisition terminals with redundant 
synchronous communications. 

Use or disclosure of data contained on this sheet i$ subject to the restriction on the title page of this proposal 
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FriedrichT. Elliott 
Program Manager and Algorithm Simulation Researcher 
LIGHTBUS Technology, Inc. 

B.S* Engineering Physics, University of Tulsa, 1977 
M.A. Physics, University of Rochester, 1979 
M.BA., Southern Methodist University, 1988 

Mr. Elliott has diverse experience in computer applications, artificial intelligence languages 
and applications, image processing and electro-optic processing, laser systems, and 
computer simulation. Twelve years of project experience at the University of Rochester 
Laboratory for Laser Energetics, Texas Instruments, and LTV Missiles and Electronics 
Group provide an in-depth background in high-speed computer applications. His project 
management experience at LTV and IT provide the key tools needed to administer this 
contract as well as contribute significantly to its technical development. Some major 
projects on which Mr. Elliott provided key design and management direction include; 

LTV Missiles and Electronics Group, 1985-1987 

Program manager for integration of expert systems, analytic models, and real-tune 
sensors for a carbon-carbon composite manufacturing process. 

Texas Instruments, 1981- 1985 m ; 

Led a research team to build a development environment combining simulation with 
expert systems which was then used to support building an expert system for air 
vehicle piloting and navigation. Program Manager and Principal Iirvestigator for the 
New Generation Electro-Optic Processing Architecture program sponsored by the 
Army Research Office where he developed autonomous target acquisition algorithms 
for guided weapons; electro-optic sensors; and multi-mode, multi-target trackers using 
distributed computing and AI architectures. 

Laboratory for Laser Energetics, 1980-1981 w 

Project supervisor for OMEGA target diagnostic functions including procuring a VAX 
11/750 computer for supporting operations data base, image processing, and 
production control. 
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u.£ DEPARTMENT OF DEFSr-.SE 



DEFENSE SMALL BUSINESS INNOVATIVE RE SEASON :.S9IR.) PROGRAM 
PHASE I - FY 1 1383 
COST PROPOSAL 

OFFEROR: LIGHTBUS Technology, Inc. 

hOmE OFFICE: 600 Goodwin Drive Richardson, Texas 75061 
WCR:. SITE: 600 Goodwin Drive Richarcson, Texas 750S1 and 

811 Knott Place Dallas, Texas 7520£ 

PROPOSAL TITLE: An Addressing Technique for Navy Traffic :n a 

Multimedia Environment 
S&IR TOPIC NO. NS9-0S7 Addressing Techftia^a for Navy Tr&:f ic in 
a Multimedia Environment 

PROPOSED COST: Firm, fixed price contract for £50, COG. 



COST BREAKDOWN: 

LABOR: Person Hours Direct 

Rate/ hour 
F\R. Fanner 300 $4S*50 
F. Elliott 135 43.50 



cverr.eaa 
Rate/hour 
$29. 70 
23. 70 



Tctal LA SOP 

TRAVEL: ;S people trips tc wash. O.C. frcrc Dal "i as } 
ai rf are s: , 

Auto rent 330 
Hotel 240 
N5ea:s 1S0 



Total TRAVEL 



CONiSU LTAN j £ : Organ i zat'i on/Person 
Smu/ m . mi lenkovic 



hours 
AO 



Pate/' hour 
2200.00 



REFO-'T COPIES: Report 

Monthly it reports 
Final Report 



Pases Copies Rste/ pa^e 
120 10 $0.20 
180 10 0 . 20 

Tctal OOP I EE. 



Total DIRECT COST 
GENERAL and ADMINISTRATIVE OVERHEAD at 6% 

PROFIT at 4.76S& 



E.-iter.ded 
Costs 
S-i. 760.00 
10,692.00 

5^4,452.00 



S 2,404.00 

Extendea 
£ d » v J 0 - C 3 

Extenoec 
S 240.00 
360 . 00 



$ 


eoo 


.00 


$45 


,4 56 


. CO 


«■ V 

to- 


,171 


- V V 


$ 2 


,272 


.00 


$50 


,000 


.00 



TOTAL CONTRACT PRICE 
21. s. No prior, current, or pending support for a similar oroposal 

b. No government furrvisned equipment requireo. 

c. Advanced payments or milestone payments reouestec. 



LIGHTBUS Technology, Inc. 




Peter R . i-enner, Secretary , Treasurer 



Date 
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Reference B 

PR, f£MUZ£ 

TO! 

(Fill in firm's name and mailing address) 
SUBJECT: SBIR Solicitation No* 89.1 

Topic No. C>S~7 

(Fill in topic no*) 



t This is to notify you that your proposal in response to the 
subject solicitation and topic nuinber has been received by 




(Signature by receiving organization (Date) 
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